Reference representation and transformation in collaborative documents

ABSTRACT

The present disclosure relates to implementing changes to a data structure, such as a formula, in a collaborative context. In certain embodiments, collaborative changes made to a formula containing references to other portions of a table are retained or account for when an undo operation is performed. In one aspect, unique identifiers are used to identify and track table features, such as columns, rows, or cells, which may be moved, deleted, or created during a collaborative session. In some instances, collaborative changes may be logged for later application or applied to commands in an undo stack to prevent loss of changes.

CROSS-REFERENCE TO RELATED APPLICATIONS

Under 35 U.S.C. §120, this application is a continuation of U.S. patentapplication Ser. No. 14/452,415 filed on Aug. 5, 2014, which isincorporated by reference herein in its entirety for all purposes.

BACKGROUND

The present disclosure relates generally to facilitating collaborativedocument development.

This section is intended to introduce the reader to various aspects ofart that may be related to various aspects of the present disclosure,which are described and/or claimed below. This discussion is believed tobe helpful in providing the reader with background information tofacilitate a better understanding of the various aspects of the presentdisclosure. Accordingly, it should be understood that these statementsare to be read in this light, and not as admissions of prior art.

Various types of documents (e.g., word processing documents,spreadsheets, slides for slideshows, and so forth, may be generated oredited on various types of processor-based systems, such as computers.In certain instances, there may be a single author or editor enteringtext or formatting changes in a sequential manner, which can beimplemented in a straight forward manner. In practice the changes madeby a single user may be implemented by applying a change (i.e., aforward action or a forward case change operation) specified by the userand by applying, as needed, any undo or redo operations specified by theuser.

However, in collaborative contexts, where changes may be generated inparallel by two or more authors, coordination of the application of thechanges made by the different parties may be problematic to implement inpractice and may represent a potential for the loss of one party'schanges. By way of example, to the extent that each party may beprovided the ability to undo their prior change to the document, changesmade by the other party may be at risk for loss if not somehow accountedfor.

The risk of data or change loss may be even greater in certain contextswhere data constructs or structures are employed, particularly to theextent such data constructs may be permitted to reference other portionsof a collaborative document that may be changed without explicitlychanging the data construct directly. For example, in a table (e.g.,spreadsheet) context, a formula may be entered into a cell of the tablewhich references or relies on other cells of the table. In such acontext, one or both of the collaborating parties may make changes tothe table (such as by inserting, deleting or moving one or morereferenced rows, columns or individual cells of the table) that affectthe formula even though the formula is not explicitly altered by eitherparty. In such a context, certain of the changes made by one party thataffect (e.g., move or delete) one or more of the referenced cells of aformula may be lost due to actions taken by the other party (such as dueto an undo operation) that fail to account for the second party'schanges.

SUMMARY

A summary of certain embodiments disclosed herein is set forth below. Itshould be understood that these aspects are presented merely to providethe reader with a brief summary of these certain embodiments and thatthese aspects are not intended to limit the scope of this disclosure.Indeed, this disclosure may encompass a variety of aspects that may notbe set forth below.

Embodiments of the present disclosure relate to implementing undo andredo operations in a collaborative context with respect to formulasprovided in a document (e.g., a spreadsheet table). In particular, tothe extent that such formulas may reference other cells within a table,an indexing scheme distinct from conventional geometric cell addressingschemes (e.g., cell A4, B5, or G32) may be selectively employed incircumstances where there is a risk of data or change loss. In oneembodiment, the indexing scheme retains a persistent and unique addressfor columns, rows, and cells of a table, even when such columns, rows,or cells are moved or repositioned (such as due to drag-and-dropoperations or sorting operations), merged and unmerged, deleted,inserted, or undeleted. Formulas, when tracked (such as when referencedin an undo operation stack (i.e., an undo stack)) may be written orrewritten to reference the columns, rows, or cells of interest using theunique identifiers, instead of or in addition to geometric coordinates,in circumstances where data or change loss may occur.

In addition, in certain embodiments changes made by a collaborator (orby a single user employing different machines or independent windows onthe same machine to edit a single document) that would affect callsreferenced by a formula may be tracked, such as in a log, or may beapplied to operations stored in an undo stack to prevent loss of thecollaborators' changes in the event of an undo operation. By way ofexample, a first collaborator performing an undo operation may have theeffect of returning a formula to an earlier state, with the potentialfor loss of intervening changes made by the collaborator. In certainembodiments, such intervening changes may be selectively tracked orapplied (as opposed to more generalized operational transform (OT)schemes) to formula-related operations in the first party's undo stackso as to prevent loss of these changes with respect to the trackedformulas.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of this disclosure may be better understood upon readingthe following detailed description and upon reference to the drawings inwhich:

FIG. 1 is a block diagram of an electronic device that may use thetechniques disclosed herein, in accordance with aspects of the presentdisclosure;

FIG. 2 is a front view of a handheld device, such as an iPhone® by AppleInc., representing an example of the electronic device of FIG. 1;

FIG. 3 is a front view of a tablet device, such as an iPad® by AppleInc., representing an example of the electronic device of FIG. 1;

FIG. 4 is a perspective view of a notebook computer, such as a MacBookPro® by Apple Inc., representing an example of the electronic device ofFIG. 1;

FIG. 5 depicts an example process flow of a conventional collaborativeoperation having loss of collaborative changes;

FIG. 6A-6F depict sample screen shots corresponding to the process flowof FIG. 5;

FIG. 7 depicts an example process flow of a collaborative operationinvolving a formula, in accordance with aspects of the presentdisclosure;

FIGS. 8A-8E depict sample screen shots corresponding to the process flowof FIG. 7;

FIG. 9 depicts a further example process flow of a collaborativeoperation involving a formula, in accordance with aspects of the presentdisclosure;

FIGS. 10A-10F depict sample screen shots corresponding to the processflow of FIG. 9;

FIG. 11 depicts an additional example process flow of a collaborativeoperation involving a formula, in accordance with aspects of the presentdisclosure;

FIGS. 12A-12F depict sample screen shots corresponding to the processflow of FIG. 11;

FIG. 13 depicts an additional example process flow of a collaborativeoperation involving a formula, in accordance with aspects of the presentdisclosure;

FIGS. 14A-14F depict sample screen shots corresponding to the processflow of FIG. 11.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

One or more specific embodiments will be described below. In an effortto provide a concise description of these embodiments, not all featuresof an actual implementation are described in the specification. Itshould be appreciated that in the development of any such actualimplementation, as in any engineering or design project, numerousimplementation-specific decisions must be made to achieve thedevelopers' specific goals, such as compliance with system-related andbusiness-related constraints, which may vary from one implementation toanother. Moreover, it should be appreciated that such a developmenteffort might be complex and time consuming, but would nevertheless be aroutine undertaking of design, fabrication, and manufacture for those ofordinary skill having the benefit of this disclosure.

When introducing elements of various embodiments of the presentdisclosure, the articles “a,” “an,” and “the” are intended to mean thatthere are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements.Additionally, it should be understood that references to “oneembodiment” or “an embodiment” of the present disclosure are notintended to be interpreted as excluding the existence of additionalembodiments that also incorporate the recited features.

The disclosure is generally directed to facilitating collaborativedocument production and editing. In particular, aspects of the presentdisclosure are directed to the collaborative manipulation of tables(such as in a spreadsheet or other applications) that may includeformulas referencing other cells within a given table. As used herein,it should be understood that collaboration (e.g., collaborative editing)may encompass more than one person who is editing or otherwise modifyinga document (i.e., a collaborative document), such as using separatemachines. It should also be understood though that collaboration may, insome instances also encompass the actions of a single user, such as auser who is accessing and modifying a document from two differentelectronic devices or even from a single device using independentwindows. Thus, collaboration as used herein encompasses the actions ofnot only multiple individuals accessing and changing a document, butalso the actions of a single individual who might be accessing andediting a document via different devices or via independent windows.

To reduce or prevent the loss of collaborative changes with respect tosuch formulas, an indexing scheme may be employed to identify and trackcells, columns, or rows of the table, even when changes have been madeby one or more of the collaborators that might remove or move a set ofcells from the table, temporarily or permanently. In addition,collaborative changes may be selectively logged or applied to an undostack of commands to prevent loss of collaborative changes in the eventof an undo operation affecting a formula.

In practice, the code for implementing such a collaborative frameworkmay be coded to operate on various types of devices or operatingsystems. Such implementations may be implemented using a suitableprogramming language, such as Objective-C®, available from Apple Inc. ofCupertino, California. Alternatively, a device agnostic approach may beemployed by implementing the collaborative code framework in conjunctionwith one or more types of browser suitable for running on differentdevices or operating systems. Such implementations may be implementedusing a suitable programming language, such as JavaScript®.

A variety of suitable electronic devices, or browsers running on suchdevices, may employ the techniques described herein to support documentgeneration or modification in a collaborative context. FIG. 1, forexample, is a block diagram depicting various components that may bepresent in a suitable electronic device 10 that may be used in theimplementation of the present approaches. FIGS. 2, 3, and 4 illustrateexample embodiments of the electronic device 10, depicting a handheldelectronic device, a tablet computing device, and a notebook computer,respectively.

Turning first to FIG. 1, the electronic device 10 may include, amongother things, a display 12, input structures 14, input/output (I/O)ports 16, one or more processor(s) 18, memory 20, nonvolatile storage22, a network interface 24, and a power source 26. The variousfunctional blocks shown in FIG. 1 may include hardware elements(including circuitry), software elements (including computer code storedon a non-transitory computer-readable medium, such as for implementing aproductivity application or web browser) or a combination of bothhardware and software elements. It should be noted that FIG. 1 is merelyone example of a particular implementation and is intended to illustratethe types of components that may be present in the electronic device 10.Indeed, the various depicted components (e.g., the processor(s) 18) maybe separate components, components of a single contained module (e.g., asystem-on-a-chip device), or may be incorporated wholly or partiallywithin any of the other elements within the electronic device 10. Thecomponents depicted in FIG. 1 may be embodied wholly or in part asmachine-readable instructions (e.g., software or firmware), hardware, orany combination thereof.

By way of example, the electronic device 10 may represent a blockdiagram of the handheld device depicted in FIG. 2, the tablet computingdevice depicted in FIG. 3, the notebook computer depicted in FIG. 4, orsimilar devices, such as desktop computers, televisions, and so forth.In the electronic device 10 of FIG. 1, the display 12 may be anysuitable electronic display used to display image data (e.g., a liquidcrystal display (LCD) or an organic light emitting diode (OLED)display). In some examples, the display 12 may represent one of theinput structures 14, enabling users to interact with a user interface ofthe electronic device 10. In some embodiments, the electronic display 12may be a MultiTouch™ display that can detect multiple touches at once.Other input structures 14 of the electronic device 10 may includebuttons, keyboards, mice, trackpads, and the like. The I/O ports 16 mayenable electronic device 10 to interface with various other electronicdevices.

The processor(s) 18 and/or other data processing circuitry may executeinstructions and/or operate on data stored in the memory 20 and/ornonvolatile storage 22. The memory 20 and the nonvolatile storage 22 maybe any suitable articles of manufacture that include tangible,non-transitory computer-readable media to store the instructions ordata, such as random-access memory, read-only memory, rewritable flashmemory, hard drives, and optical discs. By way of example, a computerprogram product containing the instructions may include an operatingsystem (e.g., OS X® or iOS by Apple Inc.), web browser (e.g., Safari® byApple Inc.), or an application program (e.g., Numbers®, Pages®, orKeynote® by Apple Inc.) or a suite of such application programs (e.g.,iWork® by Apple Inc.).

The network interface 24 may include, for example, one or moreinterfaces for a personal area network (PAN), such as a Bluetoothnetwork, for a local area network (LAN), such as an 802.11x Wi-Finetwork, and/or for a wide area network (WAN), such as a 4G or LTEcellular network. The power source 26 of the electronic device 10 may beany suitable source of energy, such as a rechargeable lithium polymer(Li-poly) battery and/or an alternating current (AC) power converter.

As mentioned above, the electronic device 10 may take the form of acomputer or other type of electronic device. Such computers may includecomputers that are generally portable (such as laptop, notebook, andtablet computers) as well as computers that are generally used in oneplace (such as conventional desktop computers, workstations and/orservers). FIG. 2 depicts a front view of a handheld device 10A, whichrepresents one embodiment of the electronic device 10. The handhelddevice 10A may represent, for example, a portable phone, a media player,a personal data organizer, a handheld game platform, or any combinationof such devices. By way of example, the handheld device 10A may be amodel of an iPod® or iPhone® available from Apple Inc. of Cupertino,Calif.

The handheld device 10A may include an enclosure 28 to protect interiorcomponents from physical damage and to shield them from electromagneticinterference. The enclosure 28 may surround the display 12, which maydisplay a graphical user interface (GUI) 30 having an array of icons 32.By way of example, one of the icons 32 may launch a web browser (e.g.,Safari® by Apple Inc.), spreadsheet application program (e.g., Numbers®by Apple Inc.), a presentation application program (e.g., Keynote® byApple Inc.), or a word processing application program (e.g., Pages® byApple Inc.). User input structures 14, in combination with the display12, may allow a user to control the handheld device 10A. For example,the input structures 14 may activate or deactivate the handheld device10A, navigate a user interface to a home screen, navigate a userinterface to a user-configurable application screen, activate avoice-recognition feature, provide volume control, and toggle betweenvibrate and ring modes. Touchscreen features of the display 12 of thehandheld device 10A may provide a simplified approach to controlling thespreadsheet or other application program. The handheld device 10A mayinclude I/O ports 16 that open through the enclosure 28. These I/O ports16 may include, for example, an audio jack and/or a Lightning® port fromApple Inc. to connect to external devices. The electronic device 10 mayalso be a tablet device 10B, as illustrated in FIG. 3. For example, thetablet device 10B may be a model of an iPad® available from Apple Inc.

In certain embodiments, the electronic device 10 may take the form of acomputer, such as a model of a MacBook®, MacBook® Pro, MacBook Air®,iMac®, Mac® mini, or Mac Pro® available from Apple Inc. By way ofexample, the electronic device 10, taking the form of a notebookcomputer 10C, is illustrated in FIG. 4 in accordance with one embodimentof the present disclosure. The depicted computer 10C may include adisplay 12, input structures 14, I/O ports 16, and a housing 28. In oneembodiment, the input structures 14 (e.g., a keyboard and/or touchpad)may be used to interact with the computer 10C, such as to start,control, or operate a GUI or applications (e.g., Safari®, Numbers®,Pages®, or Keynote® by Apple Inc.) running on the computer 10C.

With the preceding in mind, a variety of computer program products, suchas web browsers, applications or operating systems, may use or implementthe techniques discussed below to enhance the user experience on theelectronic device 10, such as when collaboratively working on a document(e.g., a spreadsheet table). Indeed, any suitable computer programproduct that provides for the creation or modification of a document(e.g., a word processing document, a spreadsheet, a slideshowpresentation, a plain text document, and so forth) in a collaborativeenvironment may employ some or all of the techniques discussed herein.Though reference to certain types of documents, such as spreadsheets,are described herein by way of example and to facilitate explanation, itshould be appreciated that the present approaches are not limited tothese types of documents but are instead more generally applicable toany collaborative context where a formula or other data construct isemployed that references other portions of the document. Thus, while thefollowing examples are provided in the context of a spreadsheetapplication, the present approaches are suitable for use in otherapplications (e.g., presentation applications, and so forth) wherecollaborative document generation and modification may be employed.

With the preceding in mind, an electronic device 10 may store and run aspreadsheet application (e.g., Numbers® from Apple Inc.) or othersuitable application used to collaboratively generate or modify adocument. The application may be stored as one or more executableroutines (which may encode and implement the actions described below) inmemory and/or storage (FIG. 1). Alternatively, such executable routinesmay be implemented as part of a web browser implementation whichsupports collaborative document development or applications runningwithin the browser that support such collaborative document development.These routines, when executed, may cause control codes and logic asdiscussed herein to be implemented on the electronic device or on aseparate electronic device (e.g., a server or other network-connecteddevice) in communication with the electronic device 10. In certainembodiments discussed herein, different users, each using an electronicdevice 10 that executes routines as discussed herein, maycollaboratively create or modify a single document.

For example, each user may make changes in a document on which they arecollaborating that contains a formula referencing other portions (e.g.,cells, rows, or columns of a table) of the document. In such acollaborative context, each device 10 is configured to implementoperations such as: (1) a forward change operation (i.e., forwardaction) in which a change input by a user is applied; and (2) an undooperation (in which a previous forward action may be undone, such as byperforming an inverse action or operation of the preceding forwardaction. In practice, as each forward action entered by a given user isentered and executed on their respective device, the forward action isalso used to generate an inverse command that is stored in an “undo”stack of commands for that device, and the forward action is forwardedto the respective devices of collaborators for execution on thecollaborator's devices. For example, user A generating a command on hisdevice to insert Row 2 into a collaborative table would cause thefollowing actions to be performed: (1) the forward action “insert Row 2”would be performed on the device of User A; (2) the forward action“insert Row 2” would be sent to the device of the collaborator (e.g.,User B) for execution on that respective device; and (3) the inversecommand, “delete Row 2,” would be generated and added to the undo stackof user A on his device.

In this example, forward actions generated at a given device may storeinformation from the document at the time of generation. Thus, onlyforward actions generated at a given device result in correspondinginverse actions being added to the respective device's undo stack. Thusthe possibility exists that invoking an undo action may result in theloss of changes made by a collaborator in an intervening time periodbetween when the undo stack command was added and when the undo commandwas invoked.

In order to better understand the following examples and discussion, itmay be useful to initially provide some general context regardingcurrent approaches for referencing cells, columns, or rows of tables.For example, what is referred to as geometric referencing herein refersto cell, column, or row references based on the address tabs or headersprovided as part of the table for user reference. In particular, columnsmay be denoted sequentially by alphabetic headers (i.e., columns A, B,C, and so forth), while rows may be denoted sequentially by numericaddressing (i.e., rows 1, 2, 3, and so forth). In such a geometricreferencing scheme, the sequence is maintained, even when changes aremade to the table. That is, an instruction to delete column C does notresult in the absence of a column C from the table, but instead resultsin the adjacent column (i.e., column D) taking the place of and beingreferenced as column C, with corresponding changes being made down theline of columns. Thus, a reference to a given column and row may, aschanges are made to the table, reference different cells at differenttimes unless the reference field is changes to account for thesechanges. While such reference tracking may be straightforward in thesingle-user case, it may prove imperfect in the collaborative contextwhere multiple users are making changes to a table in parallel and wherethe undo functionality of each user fails to account for all actionsapplied to the table.

Proceeding to the examples, and turning to FIG. 5 and FIGS. 6A-6F, aprocess flow is depicted (FIG. 5) showing a conventional approachemploying only geometric referencing in which collaborator changes maybe lost. In these figures, FIGS. 6A-6F depict representative screenshotsof a sample table to better illustrate the example.

For example, turning to FIG. 5, a process flow 80 is depictedrepresenting the interactions between a first electronic device 82 andsecond electronic device 84 working in collaboration on a document, suchas a spreadsheet table. In this example, a formula is entered (block 86)by user A on the first electronic device 82. As a consequence of thisaction, the undo stack 88 of the first electronic device is populatedwith the inverse command to restore the table to the prior state beforeexecution of the forward action entering the formula and the forwardcommand is also sent to second electronic device for execution, thoughthe undo stack 90 of the second electronic device is not populated inresponse to entering the formula. In this example, the entered formulasets the value of cell El to be the sum of cells B2 to B5, which isshown as a result 94 of the formula entry step. As will be appreciated,this formula references other cells of the table.

This is represented in FIG. 6A which depicts a sample screenshot of atable 100 in which such a command has been executed for entering such aformula 102 in cell El of the table. The cells 104 referenced by theformula 102 are shown with a dotted overlay.

Returning to the process flow, User A next performs an action (block110) to delete row 3 of the table 100. In response to this forwardaction, undo stack 88 of the first electronic device 80 is updated withthe inverse action (i.e., an insert row action) and the formula isupdated (block 112) to reflect that the value of cell El is now the sumof cells B2:B4. This is illustrated at FIGS. 6B and 6C, where FIG. 6Billustrates the row 106 (i.e., row 3) to be deleted and FIG. 6Cillustrates the effect of the deletion, including the updating of theformula 102. As will be appreciated, in the context of the geometricreferencing scheme being used, there is now a new row 3, which is whatwas previously row 4 which has now been moved up one row along with alllower rows.

In the present example, the collaborative user (e.g., User B) nowperforms an action (block 114) on the table 100, namely inserting acolumn before column B. In response to this forward action, undo stack90 of the second electronic device 88 is updated with the inverse action(i.e., a delete column action) and the formula is updated (block 116).In this example, the formula is updated to reflect that the value ofcell Fl (which was previously El before the column insertion) is the sumof cells C2 to C4 (which were cells B2:B4 prior to the columninsertion). This is illustrated in FIGS. 6D and 6E, where FIG. 6Dillustrates the column 108 (i.e., new column C) being inserted and FIG.6E illustrates the effect of the insertion, including the updating ofthe formula 102. As will be appreciated, in the context of the geometricreferencing scheme being used, there is now a new column B, with theprevious column B (and all rightward columns) having been moved to theright one place, with a corresponding change in addressing, as notedabove.

Returning to the example, after insertion of the new column by User B,

User A performs an undo (block 120) of his previous action. In responseto this undo selection, the most recently added inverse action in theundo stack 88 is performed, here an “insert row” action, and removedfrom the undo stack 88. In response to the insert row forward action,the formula 102 is returned (block 122) to a prior state, losing thechanges (i.e., the insert column action) performed by the collaborator,as illustrated in FIG. 6F.

As noted above, in this example the changes of a collaborator may belost when one party performs an undo operation when only geometricreferencing is employed. As discussed herein, the present approach mayhelp address such potential losses by employing unique identifiers thatmay help in the tracking and identification of referenced columns, rows,and cells. These unique identifiers may be used to replace or supplementgeometric references in formulas. In certain implementations, theseidentifiers may be used to store information pertaining to parts of thedocument that have been removed. In addition, in certainimplementations, intervening changes made by a collaborator may beselectively accounted for when an undo operation is performed, such aswhen such changes impact a formula of a table. In one embodiment thismay be accomplished by selectively making changes to formula-relatedoperations stored in the undo stack when such operations would beimpacted by collaborative change. In other embodiments, collaborativechanges may be logged or otherwise retained and, in the event of an undooperation, may be reapplied to a formula or table after an undo actionis performed. As will be appreciated, such embodiments for accountingfor intervening collaborator changes may also benefit from the use ofunique identifiers as discussed herein.

In one embodiment, the unique identification scheme is implemented byassigning some or all of the rows or columns of a table a unique indexwhen generated or as needed (such as in response to an undo stack beingcreated and populated or in response to a formula being entered thatreferences columns, rows, or cells of the table). As used herein, such aunique identifier may be referred to as a universal, unique identifier(UUID) (which may be shortened to [ID] within the figures to simplifyillustration). Such UUIDs may be generated and assigned sequentially, inaccordance with some predetermined generation and assignment, scheme, orin response to system provided functionality that responds to a requestfor a number by using various, transitory system parameters as inputs orseeds to generate and return unique numbers that may then be used by thealgorithms described herein as unique identifiers.

Unlike the geometric referencing described above, a row, column, or cellreferenced by UUIDs retains that referencing regardless of whateverstructural changes are made to the table. For example, a row or columnassigned a UUID (e.g., UUID 54) retains that UUID even when moved ordeleted. In certain implementations, UUIDs are assigned to rows andcolumns of a table as needed or when generated, and cells may beuniquely referenced by the combination of UUIDs for the relevant columnsand rows. In other implementations, cells themselves may be assignedUUIDs and tracked individually as needed, though such an approach may bemore resource-intensive.

An example of the use of UUIDs is provided with respect to FIGS. 7 and8A to 8E. Turning to FIG. 7, a process flow 130 is depicted representingthe interactions between the first electronic device 82 and secondelectronic device 84 working in collaboration on a document, such as aspreadsheet table. In this example, a formula is entered (block 86) byUser A on the first electronic device 82. As a consequence of thisaction, the undo stack 88 of the first electronic device is populatedwith an inverse command 152 to restore the respective cell to the priorstate before entry of the formula and the forward command is also sentto the second electronic device for execution. In this example, theentered formula sets the value of cell Fl to be the sum of cells B2 toB3, which is shown as a command result 150 of the formula entry step. Aswill be appreciated, this formula references other cells of the table.

Unlike the preceding example, however, in the implementation shown inFIGS. 7 and 8, some or all of the columns and rows of the table 100 maybe displayed and identified by a user using conventional geometricreferencing, but the system (e.g., devices 82, 84 or applicationsrunning on the devices) may employ UUIDs instead of or in addition tothe geometric references for tracking row, columns, or cells impacted byuser actions. For example, in FIG. 7 at blocks 86 and 150 and at FIG.8A, a user may input the formula “=sum(B2:B3)” in cell Fl, but thesystem, using the UUIDs assigned to the respective columns and rows oftable 100 (denoted as [IDn] in FIGS. 8A-8E) may track these rows andcolumns using the UUIDs.

This is represented in FIG. 8A which depicts a sample screenshot of atable 100 in which such a command has been executed for entering aformula 154 in cell Fl of the table. The cells 104 referenced by theformula 152 are shown with a dotted overlay. Unlike the precedingexample, however, FIG. 8A also shows the UUIDs (shown as [IDn]s) foreach row and column though, as will be appreciated, the UUIDs willtypically not be visible in this manner to a user and are here onlyillustrated to facilitate explanation. Thus, as illustrated, cell Fl maybe uniquely referenced as [ID12][ID1] and the referenced cells may alsobe uniquely referenced using the respective UUIDs. In this manner, thefirst electronic device 82 may track or utilize a version of the formulathat has been transformed to incorporate UUIDs to uniquely identify thereferenced cells, and will thereby continue to reference the propercells even if changes are made to the table 100.

This can be observed in the subsequent operations illustrated in FIG. 7.For example, after entry of the formula, the User A next deletes (block148) a column, here column B, which is uniquely identified with the UUID[ID4] in FIGS. 8A and 8B. Thus, undo stack 88 of first electronic device82 is populated with the inverse command (block 156) to insert column[ID4], which will continue to identify this column and the correspondingcells 158 (FIG. 8B) even after deletion.

In the depicted example, deletion of the column corresponding to theUUID [ID4] results in the deletion of the cells referenced by theformula 154, resulting in a reference error message (FIG. 8C) beingdisplayed (block 160). The system, however, continues to properly storeand track the referenced cells by their corresponding UUID identifiers,even though the referenced cells are deleted at the time.

In this example, User B next performs an action, inserting a row (block170) beneath existing row 2. The new row 160, when generated, isassigned a UUID, here [ID13] (FIGS. 8D and 8E). This UUID is used toidentify the new row in the undo stack 90 of the second electronicdevice 84 where a corresponding and inverse command (delete row [ID13])(block 172) is provided.

As the cells referenced by the formula are still deleted, the referenceerror message continues to be displayed to the user (FIG. 8D and FIG. 7at block 174). Likewise, the formula continues to be tracked by thesystem and is still defined by the range corresponding to UUIDs[ID4][ID3] to [ID4][ID5], though it should be appreciated that thisdefined range now also encompasses a cell of the newly added rowcorresponding to [ID13]. This can be seen more clearly when User Aperforms an undo (block 180), causing the “insert column [ID4]” actionin the undo stack 88 to be performed, as can be seen in FIG. 8E. Uponcompletion of this action, the formula 154 properly reflects thepresence of newly added row [ID13] between rows [ID3] and [IDS] (FIG. 8Eand block 182 of FIG. 7).

Turning to FIGS. 9 and FIGS. 10A to 10E, an additional example isprovided. Turning to FIG. 9, a process flow 190 is depicted representingthe interactions between the first electronic device 82 and secondelectronic device 84 working in collaboration on a document, such as aspreadsheet table. In this example, a formula is entered (block 86) byuser A on the first electronic device 82. As a consequence of thisaction, the undo stack 88 of the first electronic device is populatedwith an inverse command 152 to restore the respective cell to the priorstate before entry of the formula and the forward command is also sentto second electronic device 84 for execution. In this example, theentered formula sets the value of cell E1 to equal the value of cell A5,which is shown as a command result 192 of the formula entry step. Aswill be appreciated, this formula references another cell of the table.

As with the preceding example, the columns and rows of the table 100 areidentified by the respective systems by UUIDs for at least certainoperations, such as undo operations. The UUIDs, however, as discussedabove may be largely or entirely invisible to the users, who may insteadsee and utilize conventional geometric referencing in performing theiroperations.

Turning to the figures, at blocks 86 and 192 (FIG. 9), a user may inputthe formula “=A5” in cell E1, but the system, using the UUIDs assignedto the respective columns and rows of table 100 may track these rows andcolumns using the UUIDs. This is represented in FIG. 10A which depicts asample screenshot of a table 100 in which such a command has beenexecuted for entering a formula 198 in cell E1 of the table. The cell104 referenced by the formula 198 is shown with a dotted overlay. Aswith the preceding example, FIGS. 10A to 10F also show UUIDs (shown as[IDn]s) for each row and column though, as will be appreciated, theUUIDs will typically not be visible in this manner to a user and arehere only illustrated to facilitate explanation. Thus, as illustrated,cell E1 is uniquely referenced as [ID10][ID1] and the referenced cellmay also be uniquely referenced using the respective UUIDs. In thismanner, the first electronic device 82 may track or utilize a version ofthe formula that has been transformed to incorporate UUIDs to uniquelyidentify the referenced cell and the cell containing the formula, andwill thereby continue to reference the proper cells even if changes aremade to the table 100.

This can be observed in the subsequent operations illustrated in FIG. 9.For example, after entry of the formula, the User A next deletes (block208) the column containing the formula, i.e., column E, which isuniquely identified with the UUID [ID10] in FIGS. 10A and 10B. Thus,undo stack 88 of first electronic device 82 is populated with theinverse command (block 202) to insert column [ID10], which will continueto identify this column as well as the contents (i.e., formula 198) ofthe respective cells of column [ID10] even after deletion.

The displayed results of this operation are depicted in FIGS. 10B and10C, in which, deletion of the column (column 204 of FIG. 10B)corresponding to the UUID [ID10] results in the deletion of the cellcontaining the formula 198, resulting in no formula being displayed(FIG. 9, block 206 and FIG. 10C). As noted above, however, the systemcontinues to properly store and track the cells of the column havingUUID [ID10] and their contents (including formula 198), even though thecolumn and its cells are deleted at the time.

In this example, User B next performs an action, deleting two rows(block 210) above the referenced cell in row 5 [ID9]. The deleted rows212 have UUIDs [ID3] and [ID5] (FIG. 10D). These UUIDs are used toidentify the deleted rows in the undo stack 90 of the second electronicdevice 84 where a corresponding and inverse command (insert rows [ID3]and [ID5]) (block 214) is stored. Upon completion of this operation thecolumn corresponding to [ID10], which includes the entered formula 198,and the rows corresponding to [ID3] and [ID5] are absent from the table100 (FIG. 10E), though still known and tracked by their unique referenceidentifiers in the respective undo stacks (block 212).

When User A performs an undo operation (block 216), the “insert column[ID10]” command in the undo stack 88 is executed, as can be seen in FIG.10F. Upon completion of this action, the column corresponding to [ID10]is restored, including the formula 198. Further, the formula 198continues to reference the cell corresponding to column [ID2] and row[ID9], despite the geometric reference for this cell having changed dueto the row deletions by the collaborator, User B, as shown by block 218of FIG. 9.

As will be appreciated, use of UUIDs may be helpful in a variety ofcircumstance to prevent loss of collaborator changes or to otherwiseinsure proper referencing is maintained in a formula within a table. Insome circumstances, however, it may not be necessary to employ UUIDs forall columns or rows or over an extended period. For example, columns androws that are not impacted by a collaborator's actions may benefit fromcontinuing to be referenced geometrically. Further, once a set ofchanges is undone or is thoroughly incorporated into a document, it maybe useful to revert back to geometric referencing for a variety ofreasons, including resource management. Thus, it may be useful to employunique referencing selectively or in combination with geometricreferencing, with UUIDs only employed in circumstances where there is apossibility that changes or data may be lost, and with conversion backto geometric referencing once such a possibility is passed.

With this in mind, and turning to FIGS. 11 and 12A to 12F, a processflow 220 is depicted representing the interactions between the firstelectronic device 82 and second electronic device 84 working incollaboration on a document, such as a spreadsheet table. In thisexample, a formula is entered (block 86) by User A on the firstelectronic device 82. As a consequence of this action, the undo stack 88of the first electronic device is populated with an inverse command 152to restore the respective cell to the prior state before entry of theformula and the forward command is also sent to second electronic devicefor execution. In this example, the entered formula sets the value ofcell F1 to be the sum of cells B2 to C3, which is shown as a commandresult 222 of the formula entry step. As will be appreciated, thisformula references other cells of the table.

In this example, only some of the columns or rows of the table arereferenced using UUIDs, with other columns and rows, where possible,being referenced by the system geometrically. For example, in FIG. 11 atblocks 86 and 222 and at FIG. 12A, a user may input the formula“=sum(B2:B3)” in cell F1. Absent any other actions being taken, thesystem may continue to employ geometric referencing to track these rowsand columns (block 222).

This is represented in FIG. 12A which depicts a sample screenshot of atable 100 in which such a command has been executed for entering aformula 224 in cell F1 of the table. The cells 104 referenced by theformula 224 are shown with a dotted overlay. In this manner, the firstelectronic device 82 may track or utilize a geometrically referencedversion of the formula 224 until such time as changes are made to thetable that would indicate use of UUIDs is warranted.

For example, in the subsequent operations illustrated in FIG. 11 User Amay next delete (block 226) a column, here column B, which is uniquelyidentified with the UUID [ID4]. Thus, undo stack 88 of first electronicdevice 82 is populated with the inverse command (block 228) to insertcolumn [ID4], which will continue to identify this column and thecorresponding cells (FIG. 12B) even after deletion.

In the depicted example, deletion of the column corresponding to theUUID [ID4] results in the deletion of some of the cells referenced bythe formula 224, causing the displayed formula to be revised to“=SUM(B2:B3)” (FIG. 12C). The system, however, (block 230 of FIG. 11)selectively utilizes UUIDs to properly store and track the referencedcells by their corresponding UUID identifiers and, where feasible,geometric references. For example, as shown in Block 230, the system maytrack the formula as “E1=SUM (B2:B3 , ID4)” to account for the deletedcolumn.

In this example, User B next performs an action, inserting a row (block232) beneath existing row 2. The new row, when generated, is assigned aUUID, here [ID13] (FIGS. 12D and 12E). This UUID is used to identify thenew row in the undo stack 90 of the second electronic device 84 where acorresponding and inverse command (delete row [ID13]) (block 234) isprovided.

As the row insertion has inserted a cell into the range specified by theformula, the displayed formula is updated to “E1=SUM(B2:B4)”. The systemtracked formula, however, still tracks the deleted row [ID4]. The systemtracked formula, therefore, in this example may instead be representedat block 236 as “E1=SUM (B2:B4 , ID4)” to account for both the added rowand deleted column.

In the depicted example, User A next performs an undo (block 238),causing the “insert column [ID4]” action in the undo stack 88 to beperformed, as can be seen in FIG. 12F. Upon completion of this action,the formula 224 properly reflects the presence of newly added row 3[ID13] between rows [ID3] and [ID5] (FIG. 12F and block 239 of FIG. 11).The displayed formula (block 239) may be represented geometrically as“F1=SUM (B2:C4)” both for display and for the purposes of systemtracking. Thus, use of geometric and unique referencing may both beemployed, when appropriate, to allow system tracking of columns, rows,and cells so as to avoid loss of changes in a collaborative context.

As noted above, in certain embodiments it may also be useful to apply ortrack changes performed by a collaborator that might still be lost evenwhen UUIDs are used to reference cells, columns, and rows within atable. For example, in one embodiment actions taken by a collaborator(e.g., User B) that are determined to affect a formula referenced in theundo stack of a first user (e.g., User A) may be applied and used tomodify the stored undo actions such that, upon receiving an undocommand, the formula incorporates the action or actions taken by thecollaborator between when the undo action was stored and when the undocommand was received. Such selective application of actions to formularelated aspects of the undo stack is distinct from more generalizedapproaches, where all collaborator actions may be used to modify thecommands in the undo stack.

Alternatively, in another embodiment a log may instead be maintained ofactions taken by a collaborator which includes data that can be used todetermine the order and timing of such collaborator actions. In such anembodiment, upon performing an undo operation, the log may be referencedto “roll forward” any actions in the log needed to bring the results ofthe undo operation as they apply to a formula up to the present state ofthe table in terms of collaborative changes. Regardless of theimplementation, either of these approaches, in conjunction with the useof UUIDs or other unique identifiers may be used to help prevent theloss of changes or data to a formula in a collaborative documentsetting.

With the preceding discussion in mind, the original example in whichcollaborator changes were lost may be revisited. Turning to FIG. 13 andFIGS. 14A-14F, a process flow 240 is depicted as discussed in theexamples above and corresponding to the initial change-loss example.

In this example, a formula is entered (block 86) by user A on the firstelectronic device 82. As a consequence of this action, the undo stack 88of the first electronic device is populated with an inverse command 152to restore the respective cell to the prior state before entry of theformula and the forward command is also sent to second electronic devicefor execution. In this example, the entered formula sets the value ofcell E1 to be the sum of cells B2 to B5, which is shown as a commandresult 244 of the formula entry step. As will be appreciated, thisformula references other cells of the table.

At blocks 86 and 244 (FIG. 13), a user may input the formula“=SUM(B2:B5)” in cell E1, and the system, at this point, may track theformula using this geometric referencing. As collaborator changes aremade, however, the system may use the UUIDs assigned to certain of thecolumns and rows of table 100 and may track these rows and columns usingthe UUIDs.

As represented in FIG. 14A, a sample screenshot is depicted of a table100 in which a formula 102 is entered into cell El of the table 100. Thecells 104 referenced by the formula 102 are shown with a dotted overlay.

In the subsequent operations illustrated in FIG. 13, after entry of theformula, the User A next deletes (block 110) a row, here row 3, which isuniquely identified with the UUID [ID5] in FIGS. 14A and 14B. Thus, undostack 88 of first electronic device 82 is populated with the inversecommand (block 248) to insert row [ID5], which will continue to identifythis row and the corresponding cells 106 (FIG. 14B) even after deletion.The table 100 after deletion of row [ID5] is shown in FIG. 14C.

In the depicted example, deletion of the row corresponding to the UUID[ID5] results in the deletion of a cell (i.e., [ID4][ID5]) referenced bythe formula 102, resulting in a change to the displayed formula 102, asshown at block 250 of FIG. 13 and in FIGS. 14B and 14C. The system,however, continues to properly store and track the deleted row,including the referenced cell, by the corresponding UUID identifiers,even though the column and referenced cell are deleted at the time.

In this example, User B next performs an action, inserting a column(block 114) to the left of column B. The new column, when generated, isassigned a UUID, here [ID14] (FIG. 14E). This UUID is used to identifythe new column in the undo stack 90 of the second electronic device 84where a corresponding and inverse command (delete column [ID14]) (block254) is provided. In the depicted example, and turning to FIG. 14E,insertion of the new column [ID14] causes an update to the formula 102to reflect the movement of the formula containing cell and thereferenced cells to the right. This is also described at block 256 ofFIG. 13, where the displayed formula is shown to be “F1=SUM(C2:C4)”while the version tracked by the system utilizing UUIDs is characterizedas “[ID10][ID1]=SUM ([ID4][ID3]:[ID14][ID9]”).

When User A performs an undo operation (block 120), the “insert row[ID5]” command in the undo stack 88 is executed, as can be seen in FIG.14F. Upon completion of this action, the row corresponding to [ID5] isrestored. Thus, row [ID5] is restored but, in addition, added column[ID14], defined by its unique UUID is also still present. Thus, uponupdating of the formula 102, this formula continues to reflect thecollaborator's addition of a column, as shown in block 260 of FIG. 13,despite the return of row [ID5]. Thus, in this example, the changes ofthe collaborator are not lost when User A performs an undo operation.

The specific embodiments described above have been shown by way ofexample, and it should be understood that these embodiments may besusceptible to various modifications and alternative forms. It should befurther understood that the claims are not intended to be limited to theparticular forms disclosed, but rather to cover all modifications,equivalents, and alternatives falling within the spirit and scope ofthis disclosure.

What is claimed is:
 1. A processor-implemented method for making tablechanges, comprising: on a first electronic device, editing a document inwhich a formula is embedded, wherein the formula references one or moreother portions of the document; receiving a first change to the documentfrom a user of the first electronic device; executing the first changeto the document; and generating an undo command corresponding to aninverse of the first change and storing the undo command in an undostack on the first electronic device, wherein the undo commandincorporates unique identifiers to identify one or more portions of thedocument affected by the first change.
 2. The processor-implementedmethod of claim 1, wherein the document comprises a table and the one ormore other portions of the document comprise columns, rows, or cells ofthe table.
 3. The processor-implemented method of claim 1, wherein thefirst change to the document comprises a move, merge or unmerge, delete,or insert command that incorporates geometric referencing based onaddress tabs displayed with the document, wherein the geometricreferencing is distinct from the unique identifiers.
 4. Theprocessor-implemented method of claim 1, wherein the unique identifiersare not dependent on column indicators or row indicators displayed withthe document.
 5. The processor-implemented method of claim 1, furthercomprising: receiving a second change to the document from a differentuser of a second electronic device on which the document is also beingedited; executing the second change to the documents on the firstelectronic device; and if the second change affects the formula,updating the undo command in the undo stack based on the second change.6. The processor-implemented method of claim 1, further comprising:receiving a second change to the document from a different user of asecond electronic device on which the document is also being edited;executing the second change to the documents on the first electronicdevice; storing the second change in a log on the first electronicdevice; and applying the second change to the undo command when the undocommand is executed, if the second change affects the formula.
 7. Theprocessor-implemented method of claim 1, further comprising: receivingan undo instruction from on the first electronic device; and executingthe undo command on the first electronic device, wherein the undocommand when executed uses the unique identifiers to determine affectedportions of the document.
 8. A non-transitory, tangiblecomputer-readable medium encoding processor-executable routines, whereinthe routines, when executed by a processor cause acts to be performedcomprising: receiving edits to a document, wherein the document includesa formula incorporated into a cell of a table, wherein the formulareferences other cells of the table; receiving and executing one or moreforward actions causing changes to the table that affect the referencedcells or the cell in which the formula is entered; and generating andstoring one or more inverse actions corresponding to the one or moreforward actions in an undo stack, wherein generating the one or moreinverse actions comprises translating one or more row, column, or cellreferences to references employing unique identifiers instead ofgeometric coordinates.
 9. The non-transitory, tangible computer-readablemedium, of claim 8, wherein the changes to the table that affect thereferenced cells or the cell in which the formula is entered comprisemovement, deletion, or insertion of a row, column, or cell of the table.10. The non-transitory, tangible computer-readable medium, of claim 8,wherein the unique identifiers are not displayed with the table but oneor more address indicators corresponding use in formulating thegeometric coordinates are displayed.
 11. The non-transitory, tangiblecomputer-readable medium, of claim 8, further comprising routines, whichwhen executed by a processor cause acts to be performed comprising:updating the one or more inverse actions based on subsequent forwardactions if the subsequent forward actions impact the formula.
 12. Thenon-transitory, tangible computer-readable medium, of claim 11, whereinthe subsequent forward actions are received from a remote collaborator.13. The non-transitory, tangible computer-readable medium, of claim 8,further comprising routines, which when executed by a processor causeacts to be performed comprising: logging one or more subsequent forwardactions; and applying the one or more logged forward actions to affectedcolumns, rows, or cells of the table if an undo action is performed thataffects the formula.
 14. The non-transitory, tangible computer-readablemedium, of claim 8, further comprising routines, which when executed bya processor cause acts to be performed comprising: applying the one ormore inverse actions in the undo stack upon receipt of an undo command,wherein the one or more inverse actions, when applied, utilize theunique identifiers to affect changes to the table.
 15. A processor-basedsystem, comprising: a display; a memory storing one or more routines;and a processing component configured to execute the one or moreroutines stored in the memory, wherein the one or more routines, whenexecuted by the processing component, cause the processing component to:run an application used to generate or modify a collaborative document;receive a change to the collaborative document from a first user,wherein the change references one or more portions of the collaborativedocument using geometric references based on an addressing schemedisplayed with the collaborative document; apply the changes to thecollaborative document; generate an inverse command to the change,wherein the inverse command incorporates unique identifiers referencingthe one or more portions of the collaborative document, wherein theunique identifiers are not the geometric references; populate an undostack with the inverse command.
 16. The processor-based system of claim15, wherein the collaborative document comprises a collaborativespreadsheet table and wherein the one or more portions of thecollaborative document comprise one or more of cells, rows, or columnsof the spreadsheet table referenced using address indicators displayedwith the rows and columns of the table.
 17. The processor-based systemof claim 15, wherein the unique identifiers are generated by the systemin response to a function call to the system for a unique number. 18.The processor-based system of claim 15, wherein the one or more routinesfurther comprise one or more routines which, when executed by theprocessing component, cause the processing component to: update theinverse command based on subsequent changes received from a collaboratorif the subsequent changes affect a formula present in the collaborativedocument.
 19. The processor-based system of claim 15, wherein the one ormore routines further comprise one or more routines which, when executedby the processing component, cause the processing component to: logsubsequent changes received from a collaborator; and apply one or moreof the logged subsequent changes when the inverse command is executed ifthe subsequent changes affect a formula present in the collaborativedocument.